In conventional hardware systems, either system-on-chip (SOC) or discrete, there can be multiple master modules such as CPUs, DMAs, host processors or port interface elements that communicate with multiple slave peripherals. These peripherals include media and data ports and memory controllers. A single master can access many slave peripherals and a single peripheral needs to be accessed by many masters. The access route from a master to a slave may include multiple routing stages. These routing stages include address decoders, arbitration units, and frequency and width translation bridges.
This scheme works well for the applications that are well understood. However the application requirements are not always completely known when hardware system is being designed. The same hardware system can be used in multiple applications. In these situations fixed routes pose a limitation in achieving optimal performance.
FIG. 1 illustrates a prior art fixed routing scheme. Masters 101 through 105 control slaves 131, 132 and 139 via two crossbar switching networks SCR1 115 and SCR2 120. Master requests M1 through M3 are decoded in respective decoders 106, 107 and 108. These requests pass to arbitration unit 110. Arbitration unit 110 selects one of the requests coming from the multiple decoders 106, 107 or 108 based on priority and directs it to the intermediate point 109. Intermediate point 109 connects to a subsequent decoder 111. Master requests M4 and M5 are decoded in respective decoders 112 and 113. Arbitration units 121, 122 and 129 select one request signals from decoders 111, 112 and 113 for control of respective slaves 131, 132 and 139.
A request M1 to M3 from any one of masters 101 to 103 has to pass through two stages of arbitration at arbitration unit 110 and one of arbitration units 121, 122 and 129 before it can reach any of the destination slaves 131, 132 and 139. In contrast requests M4 or M5 from masters 104 or 105 see only one stage of arbitration at one of arbitration units 121, or 122 and 129. Clearly, the system illustrated in FIG. 1 is optimized for access for master requests M4 and M5. If the application requirement changes such that requests from any of the masters M1 through M3 need to be processed at a higher priority, or if these masters experience higher traffic than expected, then the system of FIG. 1 cannot adjust to this new requirement.
If the precise requirements of traffic from a master and concurrency of traffic with other masters are not known before design implementation, the safe approach would be add extra hardware to allow as many parallel accesses as possible. In above example, if the request profiles of masters M1 through M4 were not known, one design solution adds a separate port for all the masters M1 through M4 on SCR2. This would mean that a similar path to all the slaves S1 through S9 would have to be included for all the masters M1 through M4 in SCR2. This results in a significantly larger hardware design and can cause speed limitations or extra pipelining latency. Ignoring M5 since it represents any number of additional masters in the system, crossbar switching network SCR2 120 becomes a 4:10 crossbar instead of 2:10, doubling its size.